home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / rexx / 114 < prev    next >
Encoding:
Text File  |  1996-08-06  |  2.8 KB  |  81 lines
  1. Path: news.ox.ac.uk!news
  2. From: imc@ecs.ox.ac.uk (Ian Collier)
  3. Newsgroups: comp.lang.rexx
  4. Subject: Re: Rexx
  5. Date: 8 Jan 1996 15:51:19 GMT
  6. Organization: Oxford University Computing Laboratory
  7. Distribution: inet
  8. Message-ID: <7596.imc@comlab.ox.ac.uk>
  9. References: <4cf3bs$dmq@mn5.swip.net> <4cfhvv$c9k@starbase.nse.com>
  10. NNTP-Posting-Host: boothp2.ecs.ox.ac.uk
  11. X-Local-Date: Monday, 8th January 1996 at 3:51pm GMT
  12.  
  13. In article <4cfhvv$c9k@starbase.nse.com>, sberg@southwind.com wrote:
  14. >Not too simple, while I'm a relative newcomer to REXX I would do it this way.  I
  15. >put in a simple command into what I got here and tested it, it worked just fine.
  16.  
  17. Others have posted 'do forever/leave' solutions, but I hope you don't mind
  18. if I mention why the following is not a particularly good idea.
  19.  
  20. >call a
  21.  
  22. >loopit:
  23. >say "Do you want to rerun the program??"
  24. >Parse Upper Pull ans   /* makes response case insensitive */
  25. >    if (ans ='YES') then do
  26. >        call a
  27. >    end
  28. >    else do 
  29. >        call b
  30. >    end
  31.  
  32. >a:
  33. >'x:\path\file.exe :params'
  34. >call loopit
  35.  
  36. >b:
  37. >exit
  38.  
  39. The problem is that there are lots of CALLs here without RETURNs.  Now a
  40. CALL is usually used to do something and then return to where you were,
  41. as in this example.
  42.  
  43.    say 'Starting up'
  44.    call count
  45.    say 'Back here again'
  46.    call count
  47.    say 'Finishing'
  48.    exit
  49.  
  50.    count:
  51.    say '1 2 3 4 5 6 7 8 9 10'
  52.    return
  53.  
  54. In order to do this, the REXX interpreter must remember where it came from
  55. (and thus has to go back to), and that uses up a small piece of memory.  In
  56. your example, each time the "file.exe" is run the REXX program carries out a
  57. "call a" and a "call loopit" without ever returning, and each of these uses
  58. one of those pieces of memory.  Some interpreters (and I think OS/2 is one
  59. of them) store all these things in a particular reserved space which is
  60. quite small and will quite quickly abort with some error message telling
  61. you that there are too many nested calls (that said, you should always
  62. get at least 100 of them).
  63.  
  64. In practice, this example is pretty harmless because as soon as you say
  65. "no" the program will exit and release all its storage.  It's a good idea
  66. though to get into the habit of always returning from functions in the
  67. normal way.
  68.  
  69. Incidentally, your program would work if you changed all the CALLs into
  70. SIGNALs, as a SIGNAL is a kind of go-to and the program does not contain
  71. anything complicated that might be disrupted by a SIGNAL.  It should be
  72. noted, however, that SIGNAL is designated as an _abnormal_ change in the
  73. flow of control and so is not the best thing for this kind of program.  The
  74. best solution, since you want a loop, is to code a loop (with 'do').
  75.  
  76. Ian Collier - imc@comlab.ox.ac.uk - WWW Home Page (including REXX section):
  77. http://www.comlab.ox.ac.uk/oucl/users/ian.collier/index.html
  78.  
  79. New to this group?  Answers to frequently-asked questions can be had from
  80. http://rexx.hursley.ibm.com/rexx/ .
  81.